-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add "update_type" for joint assimilation of ASCAT SM and SMAP Tb #703
Conversation
…as into feature/amfox/smap_ascat
- added 'sfmc' obs - added/edited comments - fixed indent - minor simplifications
|
||
N_select_varnames = 0 | ||
|
||
if (any(obs_param%varname == 'Tb')) then |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need the "trim()" function here, and similarly in the next two blocks? I wonder if the "==" statement reliably produces the desired result across compilers, given that we should have trailing whitespace in %varname.
Note that obs_param is dimension(N_obs_param). Not sure if trim() works on such a 1d array.
do ii = 1,N_select_species_Tb | ||
do jj = 1,N_selected_obs | ||
if (select_species_Tb(ii) == Observations(ind_obs(jj))%species) then | ||
found_Tb_obs = .true. | ||
exit | ||
end if | ||
end do | ||
if (found_Tb_obs) exit | ||
end do |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We may want to simplify this block by teaching the get_ind_obs_lat_lon_box()
(or the related get_ind_obs()
) subroutine to (optionally) return a vector of the unique species numbers associated with the obs in ind_obs? This would be useful when we're adding new multi-sensor update_types in the future.
src/Components/GEOSldas_GridComp/GEOSlandassim_GridComp/clsm_ensupd_enkf_update.F90
Outdated
Show resolved
Hide resolved
|
||
State_incr(1,:) = (cat_progn( kk,:)%srfexc/scale_srfexc) | ||
State_incr(2,:) = (cat_progn( kk,:)%rzexc /scale_rzexc) | ||
State_incr(3,:) = (cat_progn( kk,:)%catdef/scale_catdef) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if we shouldn't look at the sensitivity of the ASCAT analysis to including/excluding catdef in the state vector. My gut feeling is that catdef shouldn't be included in the state vector, based on the history of the Tb assimilation. It's included in update_type=2 more for historical reasons than anything else. If catdef should be excluded from the state vector, we might want to settle this in the code sooner rather than later, and definitely before we start publishing results. Something to discuss on Monday.
Thanks, @amfox37, for putting this together. I committed a few small changes and added a few inline comments. |
…as into feature/amfox/smap_ascat
@gmao-rreichle A test against runs with catdef everywhere and without catchdef everywhere over 20 days suggests the latest commit works as expected with catchdef being updated only over peatland tiles |
…pd_upd_routines.F90, clsm_ensupd_enkf_update.F90, LDASsa_DEFAULT_inputs_ensupd.nml)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Branch passed all "nightly" GEOSldas tests.
We have added an additional update type 13 which has the ability to jointly assimilate multiple observation types - specifically ASCAT SM and SMAP Tb. It identifies the species associated with each observation type, and looks for observations with any of these species within the search box around a catchment. If any obs are found, it then checks to see if any are Tb species, and if so behaves like update type 8/10. If only ASCAT SM are found then it behaves like update type 2. This behaviour is controlled by setting
N_state
.Whilst this currently works well, to avoid a proliferation of update types associated with different combinations of observations we could/should probably attempt to abstract the obs search/species check "up" a level out of specific update types (with 1D or 3D options), and then call existing update types based on which observation species are actually present. Or maybe update type 13 could evolve to handle all observation combinations, and the other update types eventually sunsetted.